Skip to main content

M-Bus to LoRaWAN - Secondary Addressing

Integration manual for the ACRIOS Systems converters ACR-CV-101L-M-D and ACR-CV-101L-M-EAC with focus on secondary addressing.

Introduction​

This converter is used to retrofit existing meters with M-Bus communication to LoRaWAN communication.

Following link refers to a Lua script used within the documentation, it contains all the mentioned configuration options and functions:

M-Bus to LoRaWAN - Secondary Addressing LUA script

Typical Use-Case​

Efficient monitoring and management of heat meters plays a crucial role in optimization of energy consumption and overall operational effectiveness in the realm of district heating stations. The integration of the M-Bus to LoRaWAN converter presents a streamlined solution that allows for quick deployment and seamless connectivity for heat meter data, ensuring real-time insights and efficient control.

Scenario:

Imagine a district heating station serving a residential complex. This facility relies on a network of heat meters installed within individual apartments to monitor the heat consumption accurately. The challenge is to efficiently collect and transmit this consumption data to a central management system for billing, monitoring, and maintenance purposes.

Solution:

To overcome this challenge, the Lua script used in conjunction with ACRIOS Systems's converters incorporates Virtual ID Field Differentiation (VIF DIF) filtering. This addition provides notable benefits, including a significant reduction in transmitted bytes which comes handy given the constraints of LoRaWAN. This is particularly useful since many devices can generate large M-Bus frames.

Benefits:

  • Time and Cost Savings: The quick installation process eliminates unnecessary configuration and wiring efforts, reducing installation time and associated costs.
  • Seamless Integration: The plug-and-play nature of the solution simplifies the integration of heat meters into the district heating network, minimizing disruption to residents.
  • Reliable Communication: The external antenna ensures reliable signal propagation, maintaining consistent communication even in complex architectural environments.
  • Real-Time Insights: The solution provides real-time heat consumption data, enabling accurate billing and informed decision-making for energy optimization.
  • Remote Configuration: Both the device configuration and its software can be maintained remotely thanks to the utilization of two-way communication protocol.

What Is M-Bus?​

M-Bus (Meter-Bus) is a European standard (EN 13757-2 physical and link layer, EN 13757-3 application layer) for the remote reading of water meter, gas or electricity meters. M-Bus is also usable for other types of consumption meters. The M-Bus interface is made for communication on two wires, which is very cost-efficient. There is also a radio variant of M-Bus (Wireless M-Bus), specified in EN 13757-4.

Data on the M-Bus is transferred in telegrams which consist of one or more frames, there must be no pauses within telegrams, not even after stop bits. M-Bus uses four different telegram formats with the following structures:

Single CharacterShort FrameControl FrameLong Frame
E5hStart 10hStart 68hStart 68h
C FieldL Field = 3L Field
A FieldL Field = 3L Field
Check SumStart 68hStart 68h
Stop 16hC FieldC Field
A FieldA Field
CI FieldCI Field
Check SumUser Data (0-252 Byte)
Stop 16hCheck Sum
Stop 16h

❗ When communicating with more meters on the same M-Bus line, it is crucial to provide each slave unit with individual address (A Field). Meter can be addressed by its primary address or by its secondary address.

Primary Addressing:

AddressFunction
0Factory default address.
1-250Addresses that can be assigned to slaves. (Primary addresses)
251-252Reserved for future use.
253Indicates that addressing is performed at the network layer instead. (Secondary addressing procedure)
254Broadcast, meters reply with their addresses. (Causes collision, test purposes only)
255Broadcast, meters do not reply.

The secondary address consists of 4 parts:

  • 4 bytes being the device ID (serial #)
  • 2 bytes being the manufacturer’s identifier
  • 1 byte being the device version
  • 1 byte being the device media

The benefit of secondary addressing is that there is no need to reconfigure meter’s primary addresses and the installation can be navigated only by modifying the converters’ addressing mechanism.

Converter Integration​

Functions​

  • Adaptable payload fragmentation length
  • Configurable reading period (default interval: 1 hour)
  • Configurable initial M-bus delay (default length: 5,000 ms)
  • Configurable M-Bus parameters
  • Configurable port
  • Configurable VIF DIF filtering
  • Remote configuration using specific commands

Out of the Box Behavior​

By default after connecting the meter to the converter and powering up, the device will first scan for any available M-bus devices.

This is how it looks on first onStartup():

Initialization:

[      147][SYS]: console ready
[      150][MEM]: init done, heap 48160 bytes, bss 12472 bytes, stack 4128 bytes
[     2738][SYS]: Reset Reason: BOR reset
[     2742][SYS]: FW version: CV_FW_2.13.7
[     2749][SYS]: Model: ACR_CV_101L_M_D
[     2753][SYS]: SN: 1111
[     2756][SYS]: date / time - 2016/01/01 / 00:00:02
[     2761][SYS]: build date / time - Jan 10 2024 / 22:14:26

Loading the Lua script and starting the onStartup() section:

[     7347][STDOUT]: MBus-LoRaWAN, V2.0
[     7838][STDOUT]: ACR_CV_101L_M_D

M-Bus scan:

[     7910][HWAPI_MBUS]: MBUS FILTER not set!
[    23229][STDOUT]: Params:  1 500 0 1
[    25138][MBUS]: found id = 0x22003287, manid = 0x7704, ver = 0x14, medium = 0x07
[    29287][STDOUT]: Old filter:
[    29330][STDOUT]: 22003287  not in existing, add
[    29394][STDOUT]: New filter:
[    29441][STDOUT]: 1  = 22003287
[    29498][STDOUT]: New VIF DIF filter:
[    29547][STDOUT]: 1  = 00000000

When the scan is finished, the device sends a "Scan done" report. It's distinguished by the third byte F5. More about the command bytes are described in Commands section.

Sending the data to LoRaWAN:

[    29897][STDOUT]: TX:
[    30126][STDOUT]: V =	3605	mV

	00 : 01 01 F5 01 87 32 00 22 77 04 14 07
[    30212][LORA]: Force confirmed message after join!
[    30218][LORA]: Not joined, join and continue.
[    30249][LORAMAC]:  # === MLME-Request == #
[    30254][LORAMAC]: #               MLME_JOIN               #
[    30261][LORAMAC]: # ===== #
[    30265][LORAMAC]: STATUS      : OK
[    30272][LORAMAC]:  # == CTXS STORED == #
[    30277][LORAMAC]: Size        : 1112
[    35514][LORAMAC]:  # === MLME-Confirm == #
[    35519][LORAMAC]: STATUS      : OK
[    35524][LORAMAC]: # ===   JOINED     == #
[    35529][LORAMAC]:  OTAA
[    35532][LORAMAC]: DevAddr     :  0007AAA9
[    35538][LORAMAC]:
[    35540][LORAMAC]: DATA RATE   : DR_4
[    35549][LORAMAC]:  # == CTXS STORED == #
[    35554][LORAMAC]: Size        : 1088
[    35649][LORAMAC]:  # === MCPS-Request == #
[    35655][LORAMAC]: #            MCPS_CONFIRMED             #
[    35662][LORAMAC]: # ===== #
[    35666][LORAMAC]: STATUS      : OK
[    40870][LORAMAC]:  # === MCPS-Confirm == #
[    40876][LORAMAC]: STATUS      : OK
[    40880][LORAMAC]:  # =   UPLINK FRAME        1   = #
[    40887][LORAMAC]:
[    40890][LORAMAC]: CLASS       : A
[    40894][LORAMAC]:
[    40897][LORAMAC]: TX PORT     : 100
[    40901][LORAMAC]: TX DATA     : CONFIRMED - ACK
[    40907][LORAMAC]: 01 01 F5 01 87 32 00 22 77 04 14 07
[    40914][LORAMAC]:
[    40917][LORAMAC]: DATA RATE   : DR_4
[    40922][LORAMAC]: U/L FREQ    : 867300000
[    40927][LORAMAC]: TX POWER    : 0
[    40932][LORAMAC]: CHANNEL MASK: 00FF
[    40937][LORAMAC]:
[    40939][LORAMAC]:  # == MCPS-Indication == #
[    40945][LORAMAC]: STATUS      : OK
[    40949][LORAMAC]:  # =  DOWNLINK FRAME        0  = #
[    40956][LORAMAC]: RX WINDOW   : 1
[    40960][LORAMAC]: RX PORT     : 0
[    40965][LORAMAC]:
[    40967][LORAMAC]: DATA RATE   : DR_4
[    40972][LORAMAC]: RX RSSI     : -87
[    40977][LORAMAC]: RX SNR      : 13
[    40981][LORAMAC]:
[    40987][LORAMAC]:  # == CTXS STORED == #
[    40992][LORAMAC]: Size        : 472
[    41068][LORA]: Continue unconfirmed msg.
[    41103][STDOUT]: RX:

Throughout the sending process, the converter autonomously verifies its connection to the network server. If it detects a lack of connectivity, it automatically initiates a join request. The preceding text illustrates the successful execution of the join procedure.

onWake function:

In this section, the converter sends an M-Bus request to the connected devices and relays the received frame directly to the Network server. When this part is finished, it's followed by a "Gather report" (F4). Finally, the converter transitions into a sleep mode for the designated duration.

[    48246][STDOUT]: TX:
[    48474][STDOUT]: V =	3605	mV
	00 : 01 01 00 68 0F 0F 68 08 00 72 87 32 00 22 77 04
	10 : 14 07 3D 30 00 00 58 16
[    48585][LORAMAC]:  # === MCPS-Request == #
[    48590][LORAMAC]: #            MCPS_CONFIRMED             #
[    48597][LORAMAC]: # ===== #
[    48601][LORAMAC]: STATUS      : OK
...
[    53956][STDOUT]: RX:
[    54039][STDOUT]: TX:
[    54267][STDOUT]: V =	3604	mV
	00 : 01 01 F4 01 01
[    54365][LORAMAC]:  # === MCPS-Request == #
[    54370][LORAMAC]: #            MCPS_CONFIRMED             #
[    54377][LORAMAC]: # ===== #
[    54381][LORAMAC]: STATUS      : OK
...
[    59697][STDOUT]: RX:
[    59705][SYS]: entering sleep mode

For a more comprehensive understanding, please refer to the Commands sections below.

Hardware Used​

  1. ACR-CV-101L-M-D - M-Bus to LoRaWAN converter, battery powered
  2. ACR-CV-101L-M-EAC - M-Bus to LoRaWAN converter, externally powered

The converter allows connection to any meter or other device equipped with an M-Bus communication.

Hardware Limitations​

  • The hardware allows connecting up to 5 Unit Loads (UL) to an M-Bus line.

  • The typical battery lifetime is:

Reading and Sending IntervalBattery Lifetime
15 min2.7 years
30 min5.4 years
60 min10.8 years

This measuring was done with one M-Bus device and VIF DIF filter activated, so the payload fits a single LoRaWAN message.

Calculation was done with a single D-cell battery (19000 mAh).

In case of a longer M-Bus connection (approximately 380 meters between the meter and converter), a termination resistor (5.5 kohm) is required. This applies only for new generation (NG) of M-Bus converter (the device that allows up to 16 UL), low amount of UL and long connection (for example 380m).

Application Limitations​

  • From the nature of LoRaWAN communication it might be needed to adjust the payload size since only up to 51 bytes can be sent with SF12.
    • This solution overcomes this limitation by fragmentation of the payload. In addition, VIF DIF filter can be used to reduce the M-Bus frame size and the final payload. It also checks for the current data rate and adjusts the payload size accordingly.
  • From the nature of LoRaWAN communication it is needed to be cautious when connecting multiple sensors with frequent readings as the communication might be limited by the duty cycle.
    • As much as autonomous the communication is, the user still needs to be cautious about the wake-up period and the length of the payload. If the duty cycle exceeds the limit, the device will drop the payload and attempt to send another one next time.
  1. F4 - Gather Report Acked
  2. F5 - M-Bus Scan Done
  3. F6 - M-Bus IDs Checksum
  4. FA - Status Report
  5. FE - Configuration Acknowledge

Gather Report (0xF4)​

Payload Description
ExampleDescriptionSizeByte Number
0x01 01Packet count (1 out of 1)[2B]1-2
0xF4Command byte[1B]3
0x02Relative counter[1B]4
0x01IDs received[1B]5

M-Bus Scan Done (0xF5)​

Payload Description
ExampleDescriptionSizeByte Number
0x01 01Packet count (1 out of 1)[2B]1-2
0xF5Command byte[1B]3
0x01Apply found devices to the filter[1B]4
0x60 0x53 0x47 0x01ID 01475360[4B]5-8
0x42 0x04MAN ID 0442[2B]9-10
0x20Version[1B]11
0x02Medium[1B]12
0x31 0x57 0x54 0x01ID 01545731[4B]13-16
0x42 0x04MAN ID 0442[2B]17-18
0x20Version[1B]19
0x02Medium[1B]20
0xXXN*IDs[xB]x

Apply found devices to the filter:

  • 00 - Do not add or apply any IDs.
  • 01 - Add only scanned IDs (if an ID is stored in the memory, but not received during the scan, it is removed).
  • 02 - Add only newly found IDs.

M-Bus IDs Checksum (0xF6)​

Payload Description
ExampleDescriptionSizeByte Number
0x01 01Packet count (1 out of 1)[2B]1-2
0xF6Command byte[1B]3
0x01Filter length [= N][1B]4
0x87 32 00 23Checksum[4B]5-8

The checksum is calculated with bitwise XOR:

RES1 = 0 ⊕ (ID1) => 0 ⊕ 0x87320020 = 0x87320020
RES2 = (RES1) ⊕ (ID2) => 0x87320020 ⊕ 0x87320021 =  0x01
RES3 = (RES2) ⊕ (ID3) => 0x01 ⊕ 0x87320022 = 0x87320023
…
RESN = (RESN-1) ⊕ (IDN)

The example above shows the checksum for IDs 20003287, 21003287, and 22003287 looks like this: 0x87320023.

Status Report (0xFA)​

Payload Description
ExampleDescriptionSizeByte Number
0x01 01Packet count (1 out of 1)[2B]1-2
0xFACommand byte[1B]3
0x32 2E 30LUA script ASCII version (2.0)[3B]4-6

Configuration Acknowledge (0xFE)​

Payload Description
ExampleDescriptionSizeByte Number
0x01 0x01Packet count (1 out of 1)[2B]1-2
0xFECommand byte[1B]3
0x00Wake-up period (days)[1B]4
0x01Wake-up period (hours)[1B]5
0x00Wake-up period (minutes)[1B]6
0x01Filter length[1B]7
0x01Configuration version[1B]8
0x60 0x09M-Bus baudrate[2B]9-10
0x03Retry M-Bus reading[1B]11
0xB8 0x0BM-Bus timeout[2B]12-13
0x02OnStartup Scan mode[1B]14
0x00VIF/DIF filter index 1[1B]15
0xFFVIF/DIF filter index 2[1B]16
0xFFVIF/DIF filter index 3[1B]17
0xFFVIF/DIF filter index 4[1B]18
0xFFVIF/DIF filter index 5[1B]19
0xFFVIF/DIF filter index 6[1B]20
0xFFVIF/DIF filter index 7[1B]21
0xFFVIF/DIF filter index 8[1B]22
0xFFVIF/DIF filter index 9[1B]23
0xFFVIF/DIF filter index 10[1B]24
0xFFVIF/DIF filter index 11[1B]25
0xFFVIF/DIF filter index 12[1B]26
0xFFVIF/DIF filter index 13[1B]27
0xFFVIF/DIF filter index 14[1B]28
0xFFVIF/DIF filter index 15[1B]29
0xFFVIF/DIF filter index 16[1B]30
0x01VIF/DIF filter amount[1B]31
0x02VIF/DIF filter bytes[1B]32
0x04 0x13VIF/DIF filter[2B]33-34

VIF/DIF filter index X enables/disables a specific VIF/DIF filter for the ID with the given index.

From the example above, the last bytes 01 02 04 13 specify the VIF/DIF filter itself:

  • 01 - is the number of VIF/DIF filters for group 0, which is 1 filter.
  • 02 - is the number of following bytes, which is 2 bytes.
  • 04 13 - is the VIF/DIF filter.

For a more detailed explanation, please see the section Send Configuration (port = 02).

Initial Delay Report (0xF0 0x10)​

Payload Description
ExampleDescriptionSizeByte Number
0x01 01Packet count (1 out of 1)[2B]1-2
0xF0 10Command byte[2B]3-4
0xA0 0FInitial delay[2B]5-6

M-Bus filter Configuration (Port = 01)​

Payload Description

Clear the Filter​

Example 1DescriptionSizeByte Number
0x01Clear filter command[1B]1

Set an M-Bus ID​

Example 2DescriptionSizeByte Number
0x87 0x32 0x00 0x22Set M-Bus ID 22003287[4B]1-4

In case of multiple IDs, the downlink payload for IDs 20003287, 21003287, and 22003287 would look like this: 87 32 00 20 87 32 00 21 87 32 00 22

Uplink Response

  • Command byte F6 which contains XOR checksum of M-Bus IDs

Send a Configuration (Port = 02)​

Payload Description
ExampleDescriptionSizeByte Number
0x00Wake-up period (days)[1B]1
0x00Wake-up period (hours)[1B]2
0x1EWake-up period (minutes)[1B]3
0x60 0x09M-Bus baudrate[2B]4-5
0x03Retry M-Bus reading[1B]6
0xB8 0x0BM-Bus timeout[2B]7-8
0x02OnStartup Scan mode[1B]9
0x00VIF/DIF filter index 1[1B]10
0xFFVIF/DIF filter index 2[1B]11
0xFFVIF/DIF filter index 3[1B]12
0xFFVIF/DIF filter index 4[1B]13
0xFFVIF/DIF filter index 5[1B]14
0xFFVIF/DIF filter index 6[1B]15
0xFFVIF/DIF filter index 7[1B]16
0xFFVIF/DIF filter index 8[1B]17
0xFFVIF/DIF filter index 9[1B]18
0xFFVIF/DIF filter index 10[1B]19
0xFFVIF/DIF filter index 11[1B]20
0xFFVIF/DIF filter index 12[1B]21
0xFFVIF/DIF filter index 13[1B]22
0xFFVIF/DIF filter index 14[1B]23
0xFFVIF/DIF filter index 15[1B]24
0xFFVIF/DIF filter index 16[1B]25
0x01VIF/DIF filter amount[1B]26
0x02VIF/DIF filter bytes[1B]27
0x04 0x13VIF/DIF filter[2B]28-29

OnStartup Scan mode has 3 options:

  • 00 - disables OnStartup Scan and uses the already stored IDs.
  • 01 - stores only the IDs found during scan and removes all the stored IDs that are not found by the device.
  • 02 - only adds newly found IDs to the list, but keeps the stored ones intact.

VIF/DIF filter index X enables/disables a specific VIF/DIF filter for the ID with the given index.

From the example above, the last bytes 01 02 04 13 specify the VIF/DIF filter itself:

  • 01 - is the number of VIF/DIF filters for group 0, which is 1 filter.
  • 02 - is the number of following bytes, which is 2 bytes.
  • 04 13 - is the VIF/DIF filter.

Let's assume, we need to set-up a VIF/DIF filter for two different devices. We'll need to create a VIF/DIF filter with 2 indexes (index 0 and 1).

The VIF/DIF index specification could look like this:

00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF

or this:

01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Depending on which M-Bus ID should use VIF/DIF filter with index 0 or 1 (more below).

An example of VIF/DIF filter specification:

02 03 FD DC FF 03 FD C9 FF 02 03 FD DA FF 03 FD C8 FF

  • 02 - is the number of physical quantities/filters in this first group (index 0)
    • 03 - is the number of the following bytes
      • FD DC FF - is the first applied filter in the first group (VIF/DIF - Current)
    • 03 - is the number of the following bytes
      • FD C9 FF - is the second applied filter in the first group (VIF/DIF - Voltage)
  • 02 - is the number of physical quantities/filters in this first group (index 1)
    • 03 - is the number of the following bytes
      • FD DA FF - is the first applied filter in the second group (VIF/DIF - Current)
    • 03 - is the number of the following bytes
      • FD C8 FF - is the second applied filter in the second group (VIF/DIF - Voltage)

Uplink Response

  • Command byte FE containing a whole configuration (wake-up interval, M-Bus, and VIF/DIF filters)

Request the Configuration (Port = 03)​

ExampleDescriptionSizeByte Number
0x01Send configuration[1B]1

Uplink Response

  • Command byte FE with configuration

Request an M-Bus Scan (Port = 04)​

Payload Description
ExampleDescriptionSizeByte Number
0x01Apply newly found devices as new filter[1B]1
0xF4 01M-Bus response timeout (500 ms)[2B]2-3
0x00Filter by string (no option)[1B]4

Filter by string can be ID, Manufacturer ID, Version, Medium ...

Uplink Response
A command byte F5 with the following details about found devices:

  • M-Bus ID
  • Manufacturer ID
  • Version
  • Medium

Request an M-Bus Filter Report (Port = 05)​

ExampleDescriptionSizeByte Number
0x01Send M-Bus filter report request[1B]1

Uplink Response

  • Command byte F6 with XOR checksum of M-Bus IDs

Request a Status Report (Port = 06)​

ExampleDescriptionSizeByte Number
0x01Send status report request[1B]1

Uplink Response

  • FA command byte with a Lua script version.

Request a Reset (Port = 07)​

ExampleDescriptionSizeByte Number
0x01Send reset request[1B]1

Executes a device reset. The device starts it with circa three minutes long bootloader sequence and follows with a standard onStartup procedure.

Initial Delay Configuration (Port = 15)​

ExampleDescriptionSizeByte Number
0xA0 0x0FSet initial delay to 4 000 ms[2B]1-2

Uplink Response

  • Command byte F0 10 with the initial delay value

Request an Initial Delay Report (Port = 16)​

ExampleDescriptionSizeByte Number
0x01Send initial delay report request[1B]1

Uplink Response

  • Command byte F0 10 with the initial delay value

An Example Application with Itron M-Bus Cyble v2.0​

Itron M-Bus Cyble v2.0
Device used: Itron M-Bus Cyble v2.0

The example below uses the default Lua script. It should demonstrate the plug-and-play solution of the LoRaWAN M-Bus converter in combination with an Itron M-Bus Cyble v2.0. The second part is also an example of configuration through a downlink message.

Initial Setup​

As mentioned in the section Out of the Box Behavior, the device initially scans for available M-bus devices. When the scan is finished, the device sends a scan done report.

A scan done report looks in this case like this:

01 01 F5 01 87 32 00 22 77 04 14 07

Then converter sends a standard request to get the M-Bus data:

01 01 00 68 0F 0F 68 08 00 72 87 32 00 22 77 04 14 07 3D 30 00 00 58 16

Detailed payload description:

01 01 - This signifies it is a packet 1 out of 1
00 - This is the M-Bus filter index
68 0F 0F 68 08 00 72 87 32 00 22 77 04 14 07 3D 30 00 00 58 16 - A standard M-Bus frame follows

In this case, the preconfigured VIF/DIF filter is filtering all the data parts from the M-Bus frame, but it will be configured later, so it also sends the Volume parameter.

After that, the device goes to sleep, waking up every hour to send data from the M-Bus device again.

Here is an example of the procedure mentioned above from the perspective of the Network server: Network server log

Remote Configuration​

VIF/DIF filter​

The full M-Bus frame of the Itron M-Bus Cyble v2.0 looks like this:

68 56 56 68 08 00 72 87 32 00 22 77 04 14 07 0B
30 00 00 0C 78 87 32 00 22 0D 7C 08 44 49 20 2E
74 73 75 63 0A 20 20 20 20 20 20 20 20 20 20 04
6D 1D 14 09 31 02 7C 09 65 6D 69 74 20 2E 74 61
62 E0 12 04 13 00 00 00 00 04 93 7F 00 00 00 00
44 13 00 00 00 00 0F 10 00 1F 45 16

If parsed, the payload above would contain these values:

ID: 22003287
MAN:ACW
MED:WATER
GEN:20
ACC:11
STA:48
SIG:0
  DIF:0Ch VIF:78h Data:87320022h - FAB number 22003287
  DIF:0Dh VIF:7Ch Data:20202020202020202020h - DI .tsuc ---
  DIF:04h VIF:6Dh Data:1D140931h -  09.01.2024 20:29
  DIF:02h VIF:7Ch Data:E012h - emit .tab 4832
  DIF:04h VIF:13h Data:00000000h - Volume 0 m³
  DIF:04h VIF:93h VIFE:7Fh Data:00000000h - Volume 0 m³
  DIF:44h VIF:13h Data:00000000h - Volume 0 m³ Storage:1
MDH: 0Fh
MfgData: 10001F

An Example of VIF/DIF Configuration

  • If we only require the volume in cubic meters, we can configure the VIF/DIF filter to selectively extract the necessary value. Therefore we set the VIF/DIF filter to 04 13.

  • To do that, we'll use a downlink command with RX port = 2.

  • The following command also changes the the wake-up period from 1 hour to 30 minutes:

00 00 1E 60 09 03 B8 0B 02 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 02 04 13

A Detailed Payload Description:

00 - Wake-up period (days) - 0
00 - Wake-up period (hours) - 0
1E - Wake-up period (minutes) - 30
60 09 - M-Bus baudrate - 2400
03 - Retry M-Bus reading - 3
B8 0B - M-Bus timeout - 3000 ms
02 - onStartup scan mode - 2

info

onStartup scan modes:

  • 0 - No Startup Scan
  • 1 - Add only newly found devices
  • 2 - Add every M-Bus ID found

VIF/DIF configuration section of the payload would be:

00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 02 04 13

A Detailed Payload Description:

00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

  • The example above specifies VIF DIF filter index 0 to M-Bus ID 1
  • This frame specifies VIF DIF filter index for up to 16 M-Bus IDs

01 - amount of VIF DIF filters for group 0 - 1 filter
02 - amount of following bytes - 2 bytes
04 13 - VIF/DIF filter 1

note

The data received during the LoRaWAN transmission of M-Bus frames are not processed immediately. The commands are executed only during reporting, specifically when the device sends a frame with a command byte (for example F4). Therefore, it is advisable to schedule a downlink when the last M-Bus frame is received.

Here is an example:

Sending The Downlink TTN Downlink

Network Server Log TTN Live Data

As you can see, the network server received confirmation:

01 01 FE 00 00 1E 01 02 60 09 03 B8 0B 02 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 02 04 13

The next frame sent by the converter looks like this:

01 01 00 68 15 15 68 08 00 72 87 32 00 22 77 04 14 07 6B 30 00 00 04 13 00 00 00 00 9D 16

Description:

01 01 - packet 1 out of 1
00 - M-Bus ID index 0

The M-Bus Frame:

68 15 15 68 08 00 72 87 32 00 22 77 04 14 07 6B 30 00 00 04 13 00 00 00 00 9D 16

When parsed, the following information is extracted:

HEADER
  ID: 22003287 MAN:ACW MED:WATER GEN:20 ACC:107 STA:48 SIG:0
RECORDS
  DIF:04h (Int32) VIF:13h Data:00000000h Volume 0 m³
MDH: 00h

The outcome of this configuration is a successful application of the VIF/DIF filter and the adjustment of the wake-up period.

M-Bus payload parsing​

The payload itself is in a form of typical M-Bus frame, including the header and any M-Bus parser can be used. We recommend using one of the parsers below. Please always check for a possible licensing model.

💡 Alexander Miller M-Bus parser

💡 jMBus parser

💡 libmbus - M-bus Library from Raditex Control

Here is an example using docker to run libmbus service.

💡 ACRIOS Backend



Was anything unclear, missing or hard to understand? Please, contact us at support@acrios.com.
Further information can be found on wiki.acrios.com.
Last updated on by Ondřej Kaňovský